9장. 자주 변하는 것 따로, 안 변하는 것 따로

출처: 『소프트웨어 설계의 결합 균형』(블라드 코노노프 지음, 제이펍 2026) | 원서: Balancing Coupling in Software Design (Manning) · 입문판·PDF 재구성

코드는 분위기만 — class·this·Save 같은 말은 몰라도 됩니다. 표의 '비유'와 '위험'만 봐도 충분해요.

지금까지는 "두 부품이 얼마나 강하게 연결됐나"만 봤다.

이 장은 시간을 끼워 넣는다.

"이 부품, 앞으로 얼마나 자주 바뀔까?"

강하게 연결됐어도 둘 다 안 바뀌면 사고는 안 난다.

약하게 연결됐어도 한쪽이 매일 바뀌면 옆이 계속 흔들린다.

그러니 연결 세기만큼 변하는 빈도도 같이 봐야 한다.

0. 이 장의 새 단어 (3개)

0장에 없던 말은 딱 3개다.

나머지 어려운 말(결합·상위/하위·공유 지식·캡슐화 경계·변경 전파·인터페이스)은 전부 0장에 있다.

막히면 0장으로 돌아가면 된다.

변동성 (Volatility)

한 문장 뜻 — 한 부품이 앞으로 얼마나 자주 바뀔 것 같은가. 자주 바뀔수록 변동성이 높다.

일상비유 — 옷장 속 옷. 청바지·티셔츠는 매주 꺼낸다(변동성 높음). 명절옷·예복은 1년에 몇 번뿐이다(변동성 낮음).

한 줄 예 —

var case_matcher_changes = "매월"; // 변동성 높음
var auth_library_changes = "수년째 그대로"; // 변동성 낮음

하위 도메인 (Subdomain)

한 문장 뜻 — 회사가 하는 일(비즈니스 도메인)을 더 잘게 쪼갠 업무 영역 한 칸. 결제·배송·로그인처럼 묶이는 단위다.

일상비유 — 한 식당이라는 큰 일(도메인) 안에 주방·홀·계산대(하위 도메인)가 있는 것.

한 줄 예 —

// 고객지원 회사라는 도메인 안의 하위 도메인들
var subdomains = ["사례 매칭", "로그인", "청구", "데스크 관리"]; // 이 값이나 객체를 알게 되는 순간 결합 지점이 됩니다.

추론된 변동성 (Inferred Volatility)

한 문장 뜻 — 자기 자신은 잘 안 바뀌는 부품인데, 자주 바뀌는 이웃에 강하게 묶여서 덩달아 자주 바뀌게 되는 현상.

일상비유 — 나는 차분한 사람인데, 매일 사고 치는 친구와 한 방을 쓰면 내 일상도 매일 흔들린다.

한 줄 예 —

var dashboard_self = "거의 안 바뀜"; // 이 값이나 객체를 알게 되는 순간 결합 지점이 됩니다.
var dashboard_real = "매월 깨짐"; // 자주 바뀌는 핵심 3개에 침입 결합으로 묶인 탓

(귀납 도입) 이런 적 있죠?

우아한 설계를 끝냈는데, 요구사항이 살짝 바뀌는 바람에 코드 곳곳에 어색한 if-else가 줄줄이 붙은 적 있죠?

깔끔하던 시스템이 기능 하나 바뀌는 순간 진흙덩이가 된 적 있죠?

저자가 묻는다.

침입 결합이 가득한, 아주 엉망인 시스템을 상상해 보자.

그런데 그 부품들 중 어느 것도 앞으로 바뀔 일이 없다면?

연쇄 변경이 일어나려면 변경 자체가 있어야 한다.

바뀔 일이 없으면, 엉망인 결합도 사고를 안 친다.

아래 코드를 보자.

var case_matcher = "매월 알고리즘이 바뀜"; // 변동성 높음
var desk_form = "수년째 입력 화면 그대로"; // 변동성 낮음

둘을 같은 선반에 강하게 묶으면, 위 칸이 매월 바뀔 때마다 아래 칸까지 끌려온다.

이 "얼마나 자주 바뀌나"가 바로 변동성이다.

결합 세기에 변동성을 곱해야 진짜 비용이 나온다.

이 장에서 딱 4가지만

이 장에서 딱 4가지만

  1. 변동성 = 시간 차원 — 결합 비용 ≈ 연결 세기 × 변하는 빈도. 빈도가 0이면 비용도 0.
  2. 왜 바뀌나 (두 칸) — 솔루션 칸(버그·기술 부채·조직 변화) + 문제 칸(새 요구사항).
  3. 핵심·일반·지원 — 업무 칸(하위 도메인)을 셋으로 나눠 변동성을 미리 가늠한다.
  4. 추론된 변동성 — 자주 바뀌는 이웃에 강하게 묶이면, 안 바뀌는 부품도 덩달아 자주 바뀐다.

큰 그림: 자주 바뀌는 것과 안 바뀌는 것을 섞어서 강하게 묶지 마라.

개념 1. 변동성 — 빈도까지 봐야 진짜 비용이다

망가지는 장면

매주 입는 청바지와 1년에 한 번 입는 예복을 같은 선반에 뒤섞어 뒀다.

매주 청바지를 꺼낼 때마다 예복을 헤집는다.

청바지(자주 변함)와 예복(안 변함)을 한 칸에 묶은 게 화근이었다.

일상비유

옷장 정리.

자주 꺼내는 옷과 안 꺼내는 옷은 선반을 나눈다.

비유 코드 위험
청바지+예복 한 선반 mixed = [case_matcher, desk_form] 자주 변하는 게 안 변하는 걸 매번 헤집음
선반 분리 daily = [case_matcher]; rare = [desk_form] 한쪽 바꿔도 다른 쪽은 평화

정의 — 변동성은 한 부품이 앞으로 얼마나 자주 바뀔 것 같은가다.

그리고 결합 비용은 연결 세기만으로 안 정해진다.

결합 비용 ≈ 연결 세기 × 변동성.

변동성이 0이면, 연결이 아무리 강해도 비용은 0이다.

예시 1 (worked — 완성예): 변동성 0이면 강한 결합도 무해

// 두 부품이 침입 결합(가장 강함)으로 묶임
report.BuildInternally(data); // 강한 연결

// 하지만 두 부품 모두 "다시는 안 바뀜"이 확실하다면
var report_changes = 0; // 이 값이나 객체를 알게 되는 순간 결합 지점이 됩니다.
var data_changes = 0; // 이 값이나 객체를 알게 되는 순간 결합 지점이 됩니다.
// → 연쇄 변경이 일어날 '변경'이 없음 → 실무 비용 0

기술적으로는 나쁜 설계다.

하지만 변경이 없으니 사고도 없다.

예시 2 (worked): 약한 결합인데도 비용이 쌓이는 경우

// 약하게(데이터 결합) 연결됐지만
var total = order.GetTotal(); // 약한 연결

// 주문 규칙이 매주 바뀐다면
var order_rule_changes = "매주"; // 이 값이나 객체를 알게 되는 순간 결합 지점이 됩니다.
// → 약한 연결이라도 매주 손이 가서 비용이 누적

세기는 약해도 빈도가 높으면 비용이 쌓인다.

예시 3 (부분완성 — 빈칸 채우기)

두 부품이 강하게 묶였다. 비용을 0으로 만들려면 무엇이 0이어야 할까?

var cost = coupling_strength * ______; // 빈칸

정답은 volatility(변동성).

빈도가 0이면 곱셈 결과도 0이라, 강한 결합도 비용이 안 든다.

예시 4 (독립적용): 직접 판단

매일 바뀌는 신참 코드가, 10년째 안 바뀌는 인증 라이브러리를 침입 결합으로 의존한다.

비용이 클까 작을까?

크다.

신참 코드가 매일 바뀔 때마다(변동성 높음) 강하게 묶인 인증 라이브러리가 흔들리니까.

미니 시나리오

"이 결합 나쁜데, 고쳐야 하나요?"

→ 먼저 물어라. "이 부품 앞으로 자주 바뀌나요?"

→ 거의 안 바뀐다면 우선순위 낮음. 자주 바뀐다면 지금 고쳐라.

단순 규칙 — 결합을 볼 땐 "얼마나 강한가"와 "얼마나 자주 바뀌나"를 함께 본다. 둘 중 하나가 0이면 비용도 0이다.

개념 2. 왜 소프트웨어는 바뀌는가 — 두 칸으로 나눠 본다

망가지는 장면

"대체 이 코드는 왜 자꾸 바뀌는 거지?"

원인을 모르니 어디를 분리해야 할지도 모른다.

변경 원인을 칸으로 나눠 두면 어디가 자주 흔들릴지 미리 보인다.

일상비유

식당이 바뀌는 이유는 두 칸이다.

주방 사정(레시피 정리·새 오븐·요리사 교체)과 손님 요구(새 메뉴 달라).

비유 코드 위험
주방 사정 = 솔루션 칸 refactor(); fix_bug(); team_changed() 같은 메뉴인데 만드는 법이 바뀜
손님 요구 = 문제 칸 add_feature("새 메뉴") 메뉴 자체가 바뀜

정의 — 소프트웨어가 바뀌는 이유는 두 칸으로 나뉜다.

솔루션 칸은 설계·구현 쪽 사정이다(버그 수정·기술 부채 정리·조직 변화).

문제 칸은 비즈니스 요구 쪽이다(새 기능·기존 동작 수정).

예시 1 (worked): 솔루션 칸 — 만드는 법이 바뀐다

fix_typo_bug(); // 버그 수정 (오타~규칙 오해)
pay_back_tech_debt(); // 기술 부채 정리 → 리팩토링
team_split_into_two(); // 조직이 둘로 갈라짐 (콘웨이의 법칙)

비즈니스 요구는 그대로다.

만드는 방식만 바뀐다.

예시 2 (worked): 문제 칸 — 만드는 대상이 바뀐다

add_feature("간편 로그인"); // 새 기능
change_behavior("배송비 무료 기준 변경"); // 기존 동작 수정

손님(비즈니스)이 새 메뉴를 요구한 것이다.

문제 자체가 바뀌었다.

조직 변화 한 조각 — 콘웨이의 법칙

콘웨이의 법칙: "시스템을 설계하는 조직은, 그 조직의 의사소통 구조를 그대로 닮은 설계를 만든다."

3인 가족은 저녁 메뉴를 카톡 한 줄로 정한다.

30인 대가족 명절은 음식 담당표·도착 시간표가 필요하다.

회사가 커지면(조직 변화) 소통 방식이 바뀌고, 그게 시스템 설계까지 흔든다.

var startup = "정수기 대화로 API 변경 조율"; // 작을 땐 즉흥적
var big_corp = "공식 통합 프로토콜 필요"; // 커지면 조율 비용 폭증

예시 3 (부분완성): 어느 칸일까

var a = "Stripe SDK 보안 패치 적용"; // (A)
var b = "추천 알고리즘 개선 요청"; // (B)

(A)는 솔루션 칸(만드는 법 정리).

(B)는 문제 칸(비즈니스 요구).

예시 4 (독립적용)

"팀이 둘로 쪼개져서 결제 모듈을 따로 관리하게 됐다." 어느 칸?

솔루션 칸이다.

조직 변화(콘웨이의 법칙)는 솔루션 칸의 변경 원인이다.

왜 부품마다 빈도가 다른가

비즈니스 이해관계자는 경쟁력을 좌우하는 기능에 집중한다.

그 기능은 매주 요구가 바뀌고, 나머지는 수년째 그대로다.

그 "경쟁력 기능"이 다음 절의 핵심 하위 도메인이다.

단순 규칙 — 변경 원인을 솔루션 칸·문제 칸으로 나눠 보면, 어느 부품이 자주 흔들릴지 미리 가늠된다.

개념 3. 핵심·일반·지원 — 업무 칸으로 변동성 미리 알기

망가지는 장면

새 모듈을 만드는데, 이게 자주 바뀔 모듈인지 아닌지 짐작도 안 된다.

그래서 안 바뀔 모듈처럼 대충 강하게 묶었다가, 알고 보니 매주 바뀌는 모듈이라 매주 깨졌다.

미리 분류만 했어도 피했을 사고다.

일상비유

회사의 일(도메인)을 잘게 쪼갠 업무 칸(하위 도메인)은 세 종류다.

비밀 레시피(핵심), 남들도 쓰는 표준(일반), 그냥 거들기(지원).

비유 코드 위험
비밀 레시피(핵심) case_matcher (매월 진화) 안 바뀐다 가정하면 매번 깨짐
표준 회계(일반) stripe_billing (그냥 갖다 씀) 직접 만들면 시간 낭비
출퇴근 기록(지원) desk_form (단순 입력) 잘 안 바뀜 — 강한 결합도 OK

정의 — DDD(도메인 주도 설계)는 업무 칸을 세 종류로 나눈다.

핵심 하위 도메인은 회사의 경쟁 우위, 즉 비밀 소스다. 변동성 높음.

일반 하위 도메인은 검증된 기성 솔루션으로 충분한 칸이다. 변동성 낮음.

지원 하위 도메인은 핵심·일반을 거드는 단순 칸이다. 변동성 낮음.

3종 한눈에

구분 핵심(Core) 일반(Generic) 지원(Support)
경쟁 우위 있음 없음 없음
복잡성 높음 높음 낮음
변동성 높음 낮음 낮음
만드는 법 직접 구현 필수 기성품 갖다 씀 직접 구현(간단)
예 (WolfDesk) 사례 매칭 알고리즘 로그인·청구 데스크 관리

예시 1 (worked): 핵심 — 절대 완성되지 않는 비밀 레시피

핵심은 회사를 경쟁사와 차별화하는 칸이다.

기성품이 없어 직접 만들고, 경쟁사를 앞서려고 계속 고친다.

// 핵심: 고객지원 회사의 사례-에이전트 매칭 알고리즘
public class CaseMatcher // 이 타입은 예제에서 책임과 결합의 경계를 보여 줍니다.
{
    public dynamic Match(dynamic case) // 이 메서드의 입력과 출력이 공개 약속입니다.
    {
        // 매월 개선되는 비밀 레시피 → 변동성 높음
        /* 구현 생략 */ // 이 호출은 두 부품 사이의 연결을 보여 줍니다.
}
}

카페로 치면 시그니처 커피 레시피다.

원두 배합·추출 시간을 끊임없이 실험한다. 절대 완성된 채로 안 멈춘다.

예시 2 (worked): 일반·지원 — 잘 안 바뀌는 칸

// 일반: 남들도 다 쓰는 표준. 직접 만들 이유 없음
var billing = new StripeClient(); // 갖다 씀 → 변동성 낮음

// 지원: 단순 입력 화면. 거들기만 함
public class DeskForm // 이 타입은 예제에서 책임과 결합의 경계를 보여 줍니다.
{
    public void Save(object desk) { /* 구현 생략 */; } // 대부분 CRUD → 변동성 낮음
}

일반은 회계 소프트웨어 같다 — 내가 특별히 만들어 봐야 우위가 없다.

지원은 출퇴근 기록 같다 — 표준품이 안 맞아 직접 만들지만 자주 안 바뀐다.

예시 3 (부분완성): 분류해 보기

전자상거래의 "Netflix식 추천 알고리즘 자체 구현"은 어느 칸?

var recommendation = "자체 개발, 경쟁 우위 원천"; // 이 값이나 객체를 알게 되는 순간 결합 지점이 됩니다.
var kind = "______"; // 빈칸

정답은 핵심.

경쟁 우위를 만드는 비밀 소스라 변동성이 높다.

예시 4 (독립적용)

"KG이니시스 결제 SDK 연동"은 어느 칸?

일반이다.

검증된 기성품을 갖다 쓰고, 경쟁 우위가 없으며, 보안 패치 정도만 바뀐다.

잘못된 예 vs 올바른 예 — 자주 변하는 핵심과 안 변하는 지원을 섞기

// before (잘못): 지원이 핵심의 속사정을 직접 침범
public class DeskManager // 이 타입은 예제에서 책임과 결합의 경계를 보여 줍니다.
{
    public dynamic Assign(dynamic case) // 이 메서드의 입력과 출력이 공개 약속입니다.
    {
        var pool = matcher.AgentPool; // 핵심 내부에 직접 손댐(침입)
        pool.Agents[0].Assign(case); // 이 호출은 두 부품 사이의 연결을 보여 줍니다.
}
}
// → 핵심이 매월 바뀌면 지원도 매월 깨짐

// after (올바름): 핵심이 안정된 약속만 내주고, 지원은 그 약속만 씀
public class DeskManager // 이 타입은 예제에서 책임과 결합의 경계를 보여 줍니다.
{
    public dynamic Assign(dynamic case) // 이 메서드의 입력과 출력이 공개 약속입니다.
    {
        var agent = matcher.GetBestAgent(case); // 공개 약속만 사용
        agent.Assign(case); // 이 호출은 두 부품 사이의 연결을 보여 줍니다.
}
}
// → 핵심 내부가 매월 바뀌어도 지원은 멀쩡

소스 제어로 변동성 엿보기 — 그리고 함정

이미 굴러가는 옛 코드라면, 커밋 횟수로 변동성을 짐작할 수 있다.

var case_matcher_commits = 120; // 자주 바뀐 코드 → 변동성 높음 신호
var desk_form_commits = 3; // 거의 안 바뀐 코드 → 변동성 낮음 신호

단, 두 함정을 조심한다.

위양성 — 커밋이 많아도 다 버그 수정이면 핵심 신호가 아니다. 기능 추가·수정 커밋이라야 강한 신호다.

위음성 — 커밋이 적어도, 너무 엉망이라 손댈 엄두를 못 내서 그런 걸 수 있다. 오래된 오두막이 리모델링 기록이 없다고 멀쩡한 건 아니다.

단순 규칙 — 새 모듈은 먼저 핵심·일반·지원으로 분류한다. 핵심(자주 변함)일수록 경계에서 공유 지식을 최소화한다.

개념 4. 추론된 변동성 — 옆이 흔들리면 나도 흔들린다

망가지는 장면

단순한 대시보드 하나를 만들었다.

자기 로직은 거의 안 바뀐다.

그런데 자주 바뀌는 핵심 모듈 세 개의 속사정을 직접 들여다보게 짰더니, 셋 중 하나만 바뀌어도 대시보드가 깨졌다.

자기는 안 바뀌는데 남 때문에 매달 깨진 것이다.

일상비유

나는 차분한 사람이다.

그런데 매일 사고 치는 친구 셋과 한 방을 쓰면, 내 일상도 매일 흔들린다.

방을 따로 쓰고 연락처만 공유하면, 친구가 무슨 사고를 쳐도 내 방은 평화롭다.

비유 코드 위험
사고뭉치와 한 방(침입) kb = KnowledgeBase._internal_index 옆이 바뀔 때마다 나도 깨짐
연락처만 공유(계약) kb = knowledge.get_summary() 옆이 바뀌어도 나는 평화

정의 — 추론된 변동성은, 자기 변동성이 낮아도 변동성 높은 이웃에 강하게 묶이면 실제 변동성이 높아지는 현상이다.

지식은 종속성 화살표와 반대 방향으로 흐른다.

내가 핵심에 의존하면, 핵심이 바뀔 때 그 변경이 나에게 흘러든다.

예시 1 (worked): 잘못된 예 — 핵심 셋의 속을 직접 봄

public class SupportDashboard // 이 타입은 예제에서 책임과 결합의 경계를 보여 줍니다.
{
    public dynamic Show() // 이 메서드의 입력과 출력이 공개 약속입니다.
    {
        var m = CaseMatcher.AlgorithmState; // 핵심1 내부 침범
        var kb = KnowledgeBase.InternalIndex; // 핵심2 내부 침범
        var d = Distributor.QueueImpl; // 핵심3 내부 침범
        // 셋 중 하나만 바뀌어도 이 대시보드가 깨짐
}
}

대시보드는 안 바뀌는데, 핵심 셋의 추론된 변동성을 그대로 뒤집어쓴다.

예시 2 (worked): 올바른 예 — 안정된 약속만 의존

public class SupportDashboard // 이 타입은 예제에서 책임과 결합의 경계를 보여 줍니다.
{
    public dynamic Show() // 이 메서드의 입력과 출력이 공개 약속입니다.
    {
        var status = this.Matcher.GetStatus(); // 약속만
        var summary = this.Kb.GetSummary(); // 약속만
        var stats = this.Dist.GetQueueStats(); // 약속만
        // 핵심 셋의 내부가 매달 바뀌어도, 약속이 유지되면 안전
}
}

핵심은 내부를 자유롭게 진화시킨다.

대시보드는 변하지 않는 약속만 보므로 흔들리지 않는다.

예시 3 (부분완성): 실제 변동성 가늠

var self_volatility = "낮음"; // 이 값이나 객체를 알게 되는 순간 결합 지점이 됩니다.
var neighbor = "핵심 3개 (변동성 높음)"; // 이 값이나 객체를 알게 되는 순간 결합 지점이 됩니다.
var coupling = "침입 결합 (강함)"; // 이 값이나 객체를 알게 되는 순간 결합 지점이 됩니다.
var real_volatility = "______"; // 빈칸

정답은 높음.

강한 결합 + 높은 변동성 이웃 = 실제 변동성 폭발.

예시 4 (독립적용)

지원 하위 도메인인 ReportService가 핵심 모듈 세 개에 침입 결합으로 묶였다.

실제 변동성은?

높다.

해결책: 각 핵심이 get_status() 같은 안정된 약속을 내주게 하고, ReportService는 그 약속에만 의존한다.

미니 시나리오

"이 모듈 지원 도메인이라 안 바뀔 텐데, 왜 자꾸 손이 가지?"

→ 자주 바뀌는 핵심에 강하게 묶여 있는지 확인하라.

→ 묶여 있다면, 핵심과의 경계를 약속(계약)으로 바꿔 변동성을 절연한다.

단순 규칙 — 자주 바뀌는 이웃과는 약속(계약)으로만 연결한다. 그래야 옆이 흔들려도 나는 안 흔들린다.

한 줄 묶음표

개념 한 줄 정리
변동성 앞으로 얼마나 자주 바뀔까. 비용 ≈ 연결 세기 × 변동성
두 칸 솔루션 칸(버그·기술 부채·조직) + 문제 칸(요구사항)
핵심 비밀 소스. 직접 구현·계속 진화. 변동성 높음
일반 검증된 기성품. 갖다 씀. 변동성 낮음
지원 단순 거들기. 직접 만들지만 변동성 낮음
소스 제어 분석 커밋 수로 변동성 엿보기. 위양성·위음성 주의
추론된 변동성 자주 바뀌는 이웃에 강하게 묶이면 나도 자주 바뀜

위로 갈수록: 자주 변함 → 경계에서 적게 알아야 안전.

아래로 갈수록: 안 변함 → 강한 결합도 견딜 만함.

정리

  • 결합 비용은 연결 세기 × 변동성이다. 빈도가 0이면 강한 결합도 비용 0이다.
  • 업무 칸을 핵심·일반·지원으로 나누면 변동성을 미리 가늠할 수 있다. 핵심이 가장 자주 바뀐다.
  • 자주 바뀌는 이웃(핵심)과는 약속으로만 연결해, 변동성이 옮겨붙지 않게 한다.

한 걸음 더 ▸ (지금 몰라도 됨)

"핵심은 무조건 약하게, 지원은 무조건 강하게"가 정답은 아니다. 하위 도메인 유형은 시간이 지나며 서로 바뀌기도 한다(지원이 핵심으로 자라기도 한다). 이건 더 깊은 주제라, 지금은 "자주 변하는 것과는 적게 알수록 안전" 규칙 하나만 들고 가면 된다.

더 해보기

이미 굴러가는 코드의 변동성은 CodeScene의 핫스팟 분석으로 엿볼 수 있다. 커밋 빈도와 코드 복잡도를 교차해 단순 커밋 수보다 정확하다 (검증 2026-05-21).

다음 10장 예고 — 지금까지 본 결합의 세 차원(세기·거리·변동성)을 한데 모아 설계를 저울질하는 법을 본다. (지금 몰라도 됩니다 — 10장에서 천천히 풀려요.)

연습문제

  1. 설명. 자주 변하는 것 따로 안 변하는 것 따로의 핵심을 처음 듣는 사람에게 한 문장으로 설명하라.
  2. 구분. 두 개념(변동성 낮음, 변동성 높음)을 실제 예시 하나로 구분하라.
  3. 적용. 내 프로젝트나 학습 노트에서 이 장의 개념을 적용해 작게 개선할 지점을 하나 고르라.

부록 A. 쉬운 용어 사전

한글 용어 원문 영문명 아주 쉬운 뜻 이 장에서 나온 위치
변동성 낮음 Low Volatility 자주 바뀌지 않아 강한 결합도 큰 문제가 덜 되는 상태. 부록 B와 본문 예시
변동성 높음 High Volatility 자주 바뀌어 결합 비용이 빠르게 커지는 상태. 부록 B와 본문 예시
핵심 도메인 Core Domain 제품의 경쟁력과 직접 연결되는 업무 영역. 부록 B와 본문 예시
지원 도메인 Supporting Domain 제품 운영을 돕지만 경쟁력의 중심은 아닌 영역. 부록 B와 본문 예시

부록 B. 헷갈리는 개념 비교표

A B 구분 포인트
변동성 낮음 변동성 높음 낮으면 그대로 둘 수 있고, 높으면 완충 장치가 필요하다.
핵심 도메인 지원 도메인 핵심은 경쟁력에 직접 닿고, 지원은 운영을 돕는다.

부록 C. 더 읽을 자료

  • 이 장의 더 해보기 섹션 — 이미 모아 둔 공식 문서나 실습 링크가 있으면 여기서 먼저 확인한다.
  • 같은 책의 0장 한눈에 보기 — 용어가 막히면 0장의 용어집과 개념 척추로 돌아간다.
  • 원본 딥다이브판 같은 장 — 입문판을 읽고 큰 흐름이 잡힌 뒤 세부 논리를 더 깊게 확인한다.
  • 이 장의 flashcards.json — 읽은 직후 질문만 보고 답을 떠올리는 회상 연습에 쓴다.

부록 D. 연습문제 풀이

  1. 설명 예시. 자주 변하는 것 따로 안 변하는 것 따로는 변경이 어디로 번지는지 보고, 필요한 연결과 줄여야 할 연결을 구분하게 해 주는 장이다. 중요한 것은 용어를 외우는 것이 아니라, 이 개념이 어떤 입력·부품·결정에 영향을 주는지 말로 풀어 보는 것이다.
  2. 구분 예시. 두 개념(변동성 낮음, 변동성 높음)의 차이는 이렇게 잡으면 된다. 낮으면 그대로 둘 수 있고, 높으면 완충 장치가 필요하다. 실제 사례를 볼 때는 목적, 입력, 실패했을 때의 증상을 따로 적어 보면 헷갈리지 않는다.
  3. 적용 예시. 가장 작은 개선부터 고른다. 예를 들어 이름을 더 분명히 하거나, 평가 기준을 한 줄 추가하거나, 직접 알 필요 없는 내부 정보를 감추는 식으로 시작한다. 한 번에 크게 갈아엎는 것보다 작은 변경 하나를 확인하며 진행하는 쪽이 입문 단계에 맞다.
난이도
에피소드
질문
카드를 로딩 중...
답변

클릭하거나 Space를 눌러 뒤집기

0 / 0
학습 진도 0%
← → 이동   Space 뒤집기   R 셔플